Remove the duplicate setupMainCall call inside the try block. The process.argv was already configured at line 1295 with the . sentinel; the second call silently resets it:

// Remove this line — it replaces argv that was set with ["."]
// setupMainCall(zeroInputTools, ["dispatch_code_factory"]);
await main();

Without the fix the piped-stdin assertion passes vacuously: the test reaches tools/call via the zero-arg (non-stdin) path, not via readStdinSync.

In CJS modules, require() returns a cached module object. If readStdinSync is a local binding (not re-exported as an enumerable property), spying on the cached export does not affect the internal call inside main(). This means the readStdinSync used by main() will call through to the real implementation regardless of the spy.

The fsReadSyncSpy on fs.readSync does intercept the right level, which is why the test likely still passes — but the readStdinSyncSpy lines are misleading. Consider removing them or replacing this test with one that directly exercises readStdinSync independently, keeping the main()-level test simpler.

Line 1295 sets process.argv to include the . sentinel and mocks fs.readSync/isTTY to simulate piped stdin. But line 1315 calls setupMainCall(zeroInputTools, ["dispatch_code_factory"]) again — with no . — right before await main(), which overwrites process.argv and creates a brand-new toolsFile (leaking the first one, since only the last toolsFile value is cleaned up in afterEach). The test therefore passes for the exact same reason as the "bare invocation" test above it (empty args routed to a zero-required-fields schema), not because of stdin/sentinel handling. The elaborate fs.readSync mock and readStdinSyncSpy are dead code with respect to what the test title promises.

Fix: remove the duplicate setupMainCall call on line 1315 so the mocked stdin path from line 1295 is what actually runs through main().

readStdinSync() is invoked directly inside main() as an internal CommonJS reference, not via module.exports.readStdinSync. Spying on the exported reference from a separate require("./mcp_cli_bridge.cjs") therefore cannot patch the call site main() uses — the spy is set up, never asserted on, and mockRestore?.() even hints the author suspected it might not be a real spy. Combined with the duplicate setupMainCall issue flagged above, none of this stdin-simulation machinery in the test actually does anything; it should either be removed or the module needs to expose stdin reading through an injectable seam (e.g. accept a reader function) so it can genuinely be mocked.

shouldShowToolHelpForEmptyArgs defaults required to [] whenever matchedTool is null/undefined — which happens both for legitimately schema-less tools and for tools not found in the cached tools array at all (e.g. stale toolsFile, race with a newly-registered custom job, or a simple typo in toolName). In the "not found" case the caller previously got a fast, clear local help message; now it silently proceeds to a network round-trip that will likely fail server-side with a less actionable -32602, regressing exactly the wasteful-retry problem this function's docstring says it exists to prevent — just for a different trigger. Consider distinguishing "tool not found in cache" (show help / unknown command error, as showToolHelp already does) from "tool found with an empty/optional schema" (proceed to call).